BBS in a Box 15/BBS in a box XV-2.iso/Files II/Newton/Resources/Creative Digital Systems/PDADev32.sit/05Mann.txt

Text File | 1995-02-20 | 20.9 KB | 356 lines | [TEXT/R*ch]

Marco: The Wireless Wiz
Steve Mann

***************************************************************
Copyright (c) 1995 by Creative Digital Inc. All rights reserved.
***************************************************************

After months of waiting and speculation, Motorola has finally released their
Newton-based wireless communicator. The Marco was the hottest new product at
MacWorld - the Motorola booth was always crowded. This device helps
legitimize the Newton concept-licensable technology that can be adapted by
various Apple partners to a variety of markets.
    Marco is available through a variety of specialty retailers, resellers,
VARs, and system integrators. Although Motorola is careful to avoid
mentioning retail prices, they say that the street price should be between
$900 and $1400, depending on the level of wireless service bundled with the
purchase. Marco is currently only usable in the United States. To find the
dealer closest to you, call Motorola at 800.8.WIRELESS.
    This article is not a Marco review, merely a preview of its basic
features and a technical overview of its wireless architecture. We hope to
have a full-featured review in an upcoming issue of PDA Developers.

What's Under the Hood?
Internally, the Marco is almost identical to the MessagePad 110, although it
contains version 1.3 of the Newton OS, the version found in the MessagePad
120. It includes one MB of static RAM (480 K user RAM), a 320 x 240-pixel,
non-backlit display, an IR transceiver, a type II PCMCIA slot, a rechargeable
nickel-cadmium battery pack, and a serial port with AppleTalk built into ROM.
The biggest difference between Marco and other Newtons is that Marco includes
an ARDIS-compatible, two-way wireless modem. This addition makes the form
factor bigger (7.5 x 5.8 x 1.4 inches) and heavier (1.8 lb.) than any other
Newton.
    ARDIS is Motorola's proprietary, guaranteed-delivery wireless network.
(For a more detailed description of ARDIS, see "Wireless Data Services: Here
and Now" in PDA Developers 2.6, Nov/Dec 1994.) ARDIS is accessible from more
than 10,000 US cities, providing coverage of more than 80% of the US
population. ARDIS has good building and vehicle penetration. The typical
connection speed is 4.8 Kbps, although Motorola is upgrading the system to
19.2 Kbps in major metropolitan areas.
    Motorola offers ARDIS Personal Messaging (APM) for the Marco. It supports
standard two-way messaging between ARDIS-compatible devices, faxing,
receiving stock quotes and wireless news, and alphanumeric paging through an
operator-assisted 800 number. APM also supports the two-way transfer of
formatted Newton data, such as ink and name cards, between Marcos. You can
also sign up for ARDIS through a third-party service provider called
RadioMail. The advantage is that, in addition to all the standard APM
services, RadioMail includes Internet E-mail access.
    APM (and RadioMail) prices start at $39 a month for 100 messages, plus
$.36 for each additional message. The most expensive service level, the
Platinum pack, costs $139 a month for 650 messages plus $.21 for each
additional message. Unlike wireline messaging services, ARDIS pricing is
based on the number of delivered messages, not the connect time. APM is also
available for Windows, DOS, HP palmtop, and Macintosh systems.
    Marco's wireless hardware and software are tightly integrated into the
Newton environment. The modem is essentially attached to the bottom of the
MessagePad internals (see Figure 1). The battery pack, rated for eight hours
of intermittent, attaches to the side of the case. Overall, the engineering
is very high-quality. The wireless antenna pops out of the top of the unit.
    The software is also neatly done. It uses the In and Out boxes and adds
E-mail addresses and a Groups button (for creating messaging groups) to the
Names application. In addition, the standard Newton editor has been replaced
with Motorola's message editor (see Figure 2 on the next page), which lets
you specify different fonts and sizes, reply directly to a message, include
the original message text in a response, copy a message to the NotePad,
create prewritten form letters, and specify multiple addressees, including
carbon and blind copies.

Intelligent Agents Galore
Motorola took an unusual approach at their product introduction. Instead of
trying to feature a huge number of consumer-oriented wireless products, the
chose to highlight companies that are developing wireless
infrastructure-oriented products and services, particularly those that are
often called client/agent/server (CAS) providers. (For a detailed example of
a client/agent/server architecture, see "Portal: A PDA-to-World-Wide-Web
Interface" in PDA Developers 3.1, Jan/Feb 1995.) Although it was impossible
to get shipping and pricing information on any of the featured products or
services, they are an interesting indicator of things to come in the PDA
market, at least the way Motorola is approaching it.
    Here's brief sampling of some of Motorola's client/agent/server partners.
Surprisingly, Wayfarer, a Newton CAS product which has been in development
for  several months now, did not participate in Motorola's booth. We will
include more detailed information on all of these companies' offerings as
soon as it's available.

Independence Technologies (ITI)
ITI showed a prototype of iTRAN, a system they call middleware, which uses
"an intelligent-agent architecture, with both client-based and server-based
agents" for large-scale, high-throughput transaction processing systems. In a
nutshell, a Marco connects to a wireless server, which filters, manages, and
guarantees the completion of requests to and interactions with an enterprise
database. According to ITI, the technology is system, network, database, and
transaction monitor independent. iTRAN client and agent applications are
created in a semiautomatic fashion using the company's proprietary software.

The Memphis Group
The Memphis Group introduced Mobile App Builder, an "end-to-end software
solution... for mobile wireless access to corporate data." App Builder has
three parts: a communications server, application developer tools with a
C/C++ API to interface to the wireless communications services, and
communications shell programs for the wireless client. It is designed for
remote data access and entry. What's not clear is how you can create a
C/C++-based wireless client on a device (the Newton) when there is no C or
C++ compiler available for it.

Real World Solutions
Real World demonstrated their Intelligent Mobile Server, a Windows-based
server full of intelligent agents for message routing, filtering,
compression, and security. Thanks to John Sculley and General Magic, 1995
looks like it's shaping up to be the year of the Intelligent Agent.

Marco Development Programs
There are essentially two types of Marco/ARDIS applications you can create:
clients and hosts. Clients are programs created in NewtonScript (for the
moment) that run on the Marco; hosts are servers to the Marco clients that
interface to ARDIS. Motorola has two developer programs. The first, for
developers who want to create Marco clients, originates in the Marco group.
The second, for developers who want to create unique ARDIS hosts, originates
in the ARDIS group.

Client Developers
Motorola is very serious about having developers integrate wireless
communications into their applications. In fact, they did most of the work
for many developers - any software that uses the Newton's mail capabilities
can automatically work with both RadioMail and ARDIS Personal Messaging. For
wireless clients that need to be more tightly integrated with ARDIS, Motorola
is creating a wireless developer program designed to provide you with the
more detailed information you might need. The program should be finalized by
the time you read this. For more information contact Pat Pahl at Motorola at
415.574.7666.

Host Developers
Although probably not as interesting to most of our readers, ARDIS also has a
developer program for companies that want to create back-end, host
applications. If you call 800.57.ARDIS, for a onetime registration fee of
$300, you get the following:

* a 30-minute introductory video to ARDIS development;
* basic ARDIS documentation and test plans;
* one predefined SprintNet-accessible dial-up host port on an ARDIS
switch;
* an invitation to the ARDIS developer's conference;
* a subscription to the ARDIS Wireless Developer newsletter; and
* a subscription to On the Air, ARDIS' customer newsletter.

ARDIS has also established a publicly-available, wireless development forum
on CompuServe (GO ARDIS) where developers can get questions about host
development answered by ARDIS technical support personnel.
    When you enroll in the developer program, you have to pay for all your
air time at standard ARDIS rates. Once you successfully complete ARDIS
confidence testing of your final product, you get a refund of one-half of
your air time charges.

Newton/ARDIS Programming Models
Let's say you've decided you want to build a Marco wireless client of some
sort. You basically have three programming options. Here's a brief
description of each of them.

Peer-to-Peer
Peer-to-peer routing lets you send and receive messages between wireless
modem-equipped devices like PDAs and desktop computers. A typical application
might allow a supervisor to wirelessly transmit a work order or set of
instructions to an associate, and let the associate acknowledge receipt of
the message.
    ARDIS implements the peer-to-peer messaging model using something called
MG service. The packet is transmitted from the transmitter's radio modem to
an ARDIS wireless  base station, and from there to an ARDIS switch which is
connected to the rest of ARDIS' digital backbone.  The MG service on the
switch then forwards the packet to the recipient.  In peer-to-peer routing
there are two billable RF packets (one from the device to the switch, the
second to the receiving device).
Client/Host
Every Marco client connected to ARDIS can have a up to five different
addresses in what is called its host routing table.  Wireless messages must
be sent to one of those five hosts. Each host can be a data server, E-mail
server, gateway to a LAN, custom-designed server, or connection to another
communications network. These hosts are connected to ARDIS via a dedicated
connection.
    When a host sends a packet to ARDIS to be transmitted to the ultimate
recipient, the host can request an acknowledgment that the packet was
received.  If the receiver is turned off or out of range, the host can retry
later or wait for a notification that the device is available.  Subscribers
only get billed for messages that are actually delivered and accepted by the
host or the client.

Mail-Enabled Applications
Mail is usually discussed in the context of the client/server model, where
the mail host is the server.  You need to keep the following items in mind
when developing mail-enabled applications for the  Newton/ARDIS environment:

* The ARDIS network automatically provides mail services.
* In the Newton environment, E-mail is built into the Newton OS using the
In and Out boxes as a store and forward metaphor.
* The message-oriented nature of two-way wireless messaging is well-suited
to the store and forward nature of mail.
* Mail can be routed through public networks to information providers,
gateways, and other mail services.

    Newton's built-in applications and many commercial software packages
already support mail, including the delivery of Newton package-specific data
and ink.  A Newton user knows how to select Mail from the action slip to send
the message or data. Essentially, Marco's wireless architecture does all the
work for you.

Wireless Development Issues
When preparing a Newton application to support wireless communications, you
need to focus on both Newton client issues and a range of other issues such
as communications costs, host driver development, interfacing to the wireless
network, network latencies, and other variables. Here are two differences
that you'll likely have to deal with regardless of the type of programming
model you end up adopting.

Differences from Wireline Connections
One way a wireless network differs from a wireline connection is the
responsiveness of the network.  The bandwidth on an ARDIS cell is either 4.8
or 19.2 Kbps. Since this is usually shared with other users, the effective
throughput can range from a few hundred bytes to a few thousand bytes per
minute. This is much slower than a dedicated 14.4 Kbps wired session.
    Programmers must also take into account the nature of radio modem
connections - devices may come in and out of coverage, causing unexpected
delays in processing or responding.  Gateways can cause additional delays as
they buffer packets into groups between networks.

Solicited vs. Unsolicited Communication
Both solicited and unsolicited communication is possible with a wireless PDA
like the Marco.  Solicited communication happens when a server does not send
messages to a client until the client requests it. Unsolicited communication
is when the client has to be able to receive data without a priori knowledge
of the communication.  Some services are solicited (database access), some
are unsolicited (paging), and some, like E-mail, are hybrid.
    Unsolicited service requires that the wireless modem be continuously
powered.  Since this severely limits battery life, strictly unsolicited
services may require users to carry spare batteries or power adapters.  Some
services, such as E-mail, work best if both solicited and unsolicited
communication are supported, allowing the user the flexibility of trading off
responsiveness and battery life.

The Marco Wireless System Architecture
Now that we covered some of the background issues relating to wireless
communication, lets look at Marco's architecture. The Marco wireless system
architecture is shown in Figure 3.  It provides for:

* sharing the radio among multiple clients,
* multiple mail transport services,
* wireless and wireline mail applications, and
* several different developer APIs.

The architecture can be roughly divided into three sections, as indicated by
the highlighting in the diagram.
    The radio communications section of the architecture, on the lower left,
includes the radio hardware, Shared Radio Tool, and Wireless Manager.  These
components provide all of the software required for wireless communication
with ARDIS (and other Motorola wireless networks as well).  The Shared Radio
Tool is responsible for managing the radio hardware.  It provides an endpoint
to the Wireless Manager, which is responsible for providing both the Wireless
API to clients and any user interface components, such as preferences, that
deal directly with the radio.
    The mail section of the architecture, highlighted on the right, includes
the software to support multiple mail transports, bundled mail transport
engines, mail-based and mail-savvy applications, and the Marco mail editor.
The component labeled Wireless Mail Transports actually contains multiple
transports which share a common structure.  In the initial Marco release both
RadioMail and ARDIS Personal Messaging are provided as Mail Transports.
    The third section of the architecture includes third-party applications
and services other than mail.  There are three different APIs - your API
choice will usually be based on the type of communications service you
require.

Universal Mail Services
Applications that use a mail-based service through the In and Out boxes are
layered on top of the Universal Mail Service (UMS). Mail-Savvy programs, on
the other hand, provide mail access as a data-communications option.
Examples of Mail Savvy applications are the Marco's built-in NotePad and
Calendar applications. The UMS API is completely compatible with the existing
Newton mail API, but it provides additional mechanisms to get information
about currently available transports or register for receiving reply mail.
Applications using this interface are the most generic and will work across
multiple mail transports.

Transport-specific Applications
Some mail transports provide value-added network services.  Applications that
take advantage of these services are called transport-specific.  Since the
exact nature and API of a network service varies between transports, these
applications only run using the transport for which they are designed.  It's
difficult to discuss the potential benefits or drawbacks to these types of
applications since value-added network services vary considerably across
transports.

Dedicated Host Applications
The third type of application, a dedicated-host application, is one that
talks directly to the Marco's Wireless Manager.  These applications use the
Wireless API to send and received data across the wireless network.
Applications of this type must communicate with a specific ARDIS host.  Since
dedicated access is potentially very expensive and time consuming, this type
of application is most appropriate for vertical markets.

The Radio Communications Architecture
The radio communications portion of the architecture is shown in more detail
in Figure 4.  The major components are the hardware, the Shared Radio Tool,
and the Wireless Manager.  These components work together to provide radio
communications over ARDIS.
    The radio provides the physical communications layer and the channel
access portion of the data link layer.  The Shared Radio Tool provides two
separate interfaces.  In the current Newton OS, each communications tool may
only be used by a single client at any given time.  To accommodate multiple
radio clients, the wireless manager assumes responsibility for multiplexing
client requests to the radio.  As a result, the Shared Radio Tool's normal
interface has a data format significantly different than a typical Newton
communications tool.
    The Wireless Manager uses an endpoint to communicate with the Shared
Radio Tool.  All access to the radio from NewtonScript is made through this
endpoint. Internally, the Wireless Manager provides components for setting
the radio preferences and controlling the radio.  Most importantly, the
Wireless Manager also implements virtual endpoints which provide the Wireless
API for clients to use.  Multiple clients may instantiate virtual endpoints
simultaneously - the Wireless Manager coordinates the use of the real
endpoint among the multiple virtual endpoints.

The Mail Architecture
Figure 5 shows the details of the Mail Architecture.  Three major components
are involved in sending mail - an application, the Universal Mail Service,
and a Mail Transport.  The application sending the mail may be the mail
application itself, a third party application layered on top of mail
services, or any Newton application that supports the standard mail routing
service.  The Universal Mail Service provides a consistent API for all mail
transports.  Applications need not know the difference between the individual
mail transports supplied by third parties.
    The Mail Application has a mail editor and a log overview.  The mail
editor uses the Mail Slip and I/O Box provided by the Universal Mail Service.
 Other applications that need to send or receive mail use these interfaces as
well.  Universal Mail Service provides an extensible logging capability - the
results are stored in a Mail Log Soup.  The Log Overview provides the user
with convenient access to the data in this soup.
    The user selects and configures mail transports through the Mail Prefs
component.  Custom preferences may be optionally supplied by the transport as
"Extended Prefs".  In addition, the transport may optionally supply a
registration view that allows the user to register that transport.
    The Mail Slip allows the user to address and submit a piece of mail.  It
uses the transport's Attributes to determine what features are available for
the specific transport.  In addition, the transport can supply an Extended
Mail Slip that supports custom mail features .
    The Universal Mail Service owns the mail InBox/OutBox and makes calls to
the transport's I/O functions to send mail.  When receiving mail, the
transport should deliver it to the I/O box so that the Universal Mail Service
can dispatch it appropriately.

Summary
That's a quick look at what makes Marco unique. Marco represents a whole new
class of Newton device - wireless PDAs. Finally, it's possible to be in
touch, anytime, anywhere. Motorola has made the fewest possible changes to
the basic Newton architecture, and they've made every attempt to simplify the
task of adding wireless communications to all Newton applications. At the
same time, they've provided a good set of hooks and lower-level APIs so that
you can create robust, wireless-centric applications with minimum effort. It
will be interesting to see what types of wireless applications appear in the
coming months.